\chapter{Funktionssicht}
\label{cha:konzept_funktionssicht}
In diesem Kapitel wird die Struktursicht des Konzepts aus \autoref{cha:konzept_struktursicht} um die Funktionssicht erweitert. Sämtliche hier behandelten Funktionalitäten orientieren sich an den funktionalen Anforderungen aus \autoref{sec:funktionale_anforderungen}.

\section{Allgemein}
\label{sec:konzept_funktionssicht_allgemein}
In diesem Abschnitt werden alle funktionalen Anforderungen aufgegriffen, die keine direkte Abhängigkeit zur XCommander Library oder XCommander Erweiterung haben.

\subsection[XCommander installieren]{XCommander installieren (\reffrequirement{frq:xcommander_installieren})}
Die Installation der Erweiterung ist keine Funktionalität der Erweiterung, sonder des jeweiligen Browsers. Abhängig vom jeweiligen Browser muss  die Erweiterung als komprimiertes Archiv mit der entsprechenden Manifest-Datei vorhanden sein. 

Bei Chrome und Safari Erweiterungen kann in der Manifest-Datei angegeben werden in welchem Verzeichnis sich z.B. Content Scripts befinden. Opera Erweiterungen basieren auf dem \acrshort{w3c} Widgets Standard, dieser erwartet eine normierte Verzeichnisstruktur damit die Installation erfolgreich durchgeführt werden kann. Deshalb muss sich die  browserunabhängigen Erweiterung ebenfalls nach der Verzeichnisstruktur des \acrshort{w3c} Widgets Standards richten.

\subsection[XCommander updaten]{XCommander updaten (\reffrequirement{frq:xcommander_updaten})}
\label{subsec:konzept_funktionssicht_allgemein_xcommander_updaten}
Wie bei der Installation der Erweiterung handelt es sich beim Updaten der Erweiterung um eine Funktionalität des Browsers. Wird die Erweiterung über den Add-On Store des jeweiligen Browser verteilt, erfolgt die Update-Unterstützung automatisch. Wird die Erweiterung auf einem eigenen Server verteilt, muss die Update-Unterstützung bei allen drei Browsern in der Manifest-Datei dementsprechend angegeben werden.

\subsection[XCommand debuggen]{XCommand debuggen (\reffrequirement{frq:xcommand_debug})}
XCommands können in Chrome, Safari und Opera gedebuggt werden. Der Code eines XCommands wird als String im \verb|localStorage| gespeichert. Zur Laufzeit wird dieser String durch die JavaScript \verb|eval()|"=Methode ausgeführt, somit können XCommands, wie normale JavaScript"=Objekte im Browser gedebuggt werden.

\section{XCommander Library}
\label{sec:konzept_funktionssicht_xcommander_library}
Dieser Abschnitt konzipiert alle Library-spezifischen funktionalen Anforderungen aus \autoref{sec:anforderungen_xcommander_library}.
\subsection[XCommander Messaging]{XCommander Messaging (\reffrequirement{frq:xcommander_messaging})}
\begin{figure}[H]
   \centering
   \includegraphics[width=0.8\textwidth]{images/sequenzdiagramm_messaging}
   \caption{Sequenzdiagramm - Messaging}
   \label{fig:sequenzdiagramm_messaging}
\end{figure}
Das Sequenzdigramm in \autoref{fig:sequenzdiagramm_messaging} zeigt das funktionale Prinzip, wie der Message"=Client mit dem Message"=Server kommuniziert. Message"=Client und Message"=Server kennen die Implementation der Messaging \acrshort{api} der unterstützten Browser nicht. Sie delegieren Nachrichten an die konkreten Browser"=Objekte und werden durch diese über eingehende Nachrichten informiert. Das generische Browser"=Objekt repräsentiert die abstrakte Schnittstelle und muss von jedem konkreten Browser"=Objekt implementiert werden (\vgl{\autoref{sec:konzept_xcommander_library}}).

\noindent Der sequenzielle Ablauf erfolgt nach den folgenden Schritten:
\begin{enumerate}
  \item Der Message"=Client delegiert eine Nachricht an das konkrete Browser Objekt.
  \item Das konkrete Browser"=Objekt im Content Process verschickt die Nachricht über seine proprietäre Schnittstelle der Messaging \acrshort{api}.
  \item Das konkrete Browser"=Objekt im Extension Process empfängt die Nachricht über sein proprietären Message"=Listener und leitet die Nachricht an den Message"=Server weiter.
  \item Nachdem die Nachricht im Extension Process dem Empfänger übermittelt und von ihm verarbeitet wurde, beantwortet der Message"=Server die Nachricht und leitet die Antwort an das konkrete Browser"=Objekt im Extension Process weiter.
  \item Das konkrete Browser"=Objekt im Extension Process verschickt die Antwort über seine proprietäre Schnittstelle der Messaging \acrshort{api}.
  \item Das konkrete Browser"=Objekt im Content Process empfängt die Antwort und leitet sie dem Message"=Client weiter, dieser stellt die Antwort schlussendlich dem ursprünglichen Absender zu.
\end{enumerate}

\subsection[XCommander XmlHttpRequest]{XCommander XmlHttpRequest (\reffrequirement{frq:xcommander_xhr})}
\begin{figure}[H]
   \centering
   \includegraphics[width=0.8\textwidth]{images/sequenzdiagramm_xhr}
   \caption{Sequenzdiagramm - XHR aus einem XCommand}
   \label{fig:sequenzdiagramm_xhr}
\end{figure}
Das Sequenzdiagramm in \autoref{fig:sequenzdiagramm_xhr} zeigt den sequentiellen Ablauf von einem \verb|XmlHttpRequest| aus einem XCommand.
Der Übersichtlichkeit halber wurden die konkreten Browser"=Objekte im Content und Extension Process weggelassen. Die gesamte Kommunikation vom initialen Aufruf aus dem XCommand bis zur Beantwortung erfolgt asynchron.

\noindent Der sequenzielle Ablauf erfolgt nach den folgenden Schritten:
\begin{enumerate}
  \item Das XCommand"=Objekt startet einen \verb|XmlHttpRequest|.
  \item Das XHRStub"=Objekt reicht den Request an den Message"=Client weiter.
  \item Der Message"=Client sendet via Messaging \acrshort{api} den Request als Nachricht an den Message"=Server im Extension Process.
  \item Der Message"=Server packt die Nachricht aus und sendet den Request via dem registrierten Listener an das XHR"=Objekt.
  \item Das XHR"=Objekt beantwortet den Request und übergibt der Callback"=Methode die Response"=Daten.
  \item Der Message"=Server verpackt die Response"=Daten in einer Nachricht und sendet diese zurück an den Message"=Client im Content Process.
  \item Der Message"=Client packt die Nachricht aus und leitet die Response"=Daten über die Callback"=Methode ans XHRStub"=Objekt weiter.
  \item Das XHRStub"=Objekt reicht die Response"=Daten über die Callback"=Methode ans XCommand"=Objekt zurück.
\end{enumerate}

\subsection[XCommander Local Storage]{XCommander Local Storage (\reffrequirement{frq:xcommander_local_storage})}
\begin{figure}[H]
   \centering
   \includegraphics[width=0.8\textwidth]{images/sequenzdiagramm_storage}
   \caption{Sequenzdiagramm - XCommands aus dem Local Storage laden}
   \label{fig:sequenzdiagramm_storage}
\end{figure}

Das Sequenzdiagramm in \autoref{fig:sequenzdiagramm_storage} zeigt den sequentiellen Ablauf beim Laden aller installierten XCommands aus dem Local Storage.
Der Übersichtlichkeit halber wurden die konkreten Browser"=Objekte im Content und Extension Process weggelassen.


\noindent Der sequenzielle Ablauf erfolgt nach den folgenden Schritten:
\begin{enumerate}
  \item Das \acrshort{ui}"=Panel fordert alle installierten XCommands an.
  \item Das XCommandStub"=Objekt leitet den Request an den Message"=Client weiter.
  \item Der Message"=Client sendet via Messaging \acrshort{api} den Request als Nachricht an den Message"=Server im Extension Process.
  \item Der Message"=Server packt die Nachricht aus und sendet den Request via dem registrierten Listener an das XCommand"=Objekt.
  \item Das XCommand"=Objekt fordert synchron alle gespeicherten Keys vom Storage"=Objekt an.
  \item Das Storage"=Objekt beantwortet die synchrone Anfrage und retourniert alle gespeicherten Keys im Local Storage.
  \item Das XCommand"=Objekt iteriert synchron durch alle Keys und überprüft, ob es sich um ein Key eines XCommands handelt. Falls der Key von einem XCommand stammt, fordert er das XCommand vom Storage"=Objekt an.
  \item Das Storage"=Objekt liefert synchron für jeden angeforderten Key das zugehörige XCommand zurück.
  \item Das XCommand"=Objekt beantwortet den Request und übergibt der Callback"=Methode die Response"=Daten.
  \item Der Message"=Server verpackt die Response"=Daten in einer Nachricht und sendet diese zurück an den Message"=Client im Content Process.
  \item Der Message"=Client packt die Nachricht aus und leitet die Response"=Daten über die Callback"=Methode ans XCommandStub"=Objekt weiter.
  \item Das XCommandStub"=Objekt reicht die Response"=Daten über die Callback"=Methode ans \acrshort{ui}"=Panel zurück.
\end{enumerate}

\section{XCommander Erweiterung}
\label{sec:konzept_funktionssicht_xcommander_erweiterung}
Die Architektur der XCommander Erweiterung basiert auf den funktionalen Anforderungen aus \autoref{sec:anforderungen_xcommander_erweiterung} und den Qualitätsanforderungen aus \autoref{sec:qualitätsanforderungen}. Die funktionalen Anforderungen wurden anhand der Kenntnisse und in Anlehnung an das Projekt \gls{ubiquity} der Mozilla Labs ermittelt. Daher werden einzelne konzeptionelle Ansätze des \gls{ubiquity} Projekts in der XCommander Erweiterung aufgegriffen und übernommen (\vgl{\cite[]{mozilla2011_ubiquity}).


\subsection[XCommander verwalten]{XCommander verwalten (\reffrequirement{frq:xcommander_verwalten})}
Das Backend der XCommander Erweiterung basiert auf der funktionalen Anforderung \reffrequirement{frq:xcommander_verwalten}. Die Administrationsseite beinhaltet zwei Arten von Funktionalitäten:

\begin{itemize}
  \item \textbf{Erweiterungspezifische Einstellungen:} Die erweiterungsspezifischen Einstellungen beinhalten Einstellungen die global für die ganze Erweiterung gültig sind. Dies kann z. B. die Sprache der Erweiterung, die Sprache des \glspl{parser} oder die Tastenkombination um die Erweiterung zu öffnen sein.
  \item \textbf{XCommand-spezifische Eistellungen:} Die XCommand-spezifischen Einstellungen sind Einstellungen die direkt oder indirekt eine Abhängigkeit zu einem XCommand haben. Grundsätzlich basieren diese Einstellungen auf den folgenden funktionalen Anforderungen:
  	\begin{compactitem}
     \item \textbf{XCommand installieren (\reffrequirement{frq:xcommand_installieren})}
     \item \textbf{XCommand deinstallieren (\reffrequirement{frq:xcommand_deinstallieren})}
     \item \textbf{XCommand updaten (\reffrequirement{frq:xcommand_updaten})}
     \item \textbf{XCommand de- bzw. reaktivieren (\reffrequirement{frq:xcommand_deactivate})}
  	\end{compactitem}
\end{itemize}


\subsection[XCommand installieren]{XCommand installieren (\reffrequirement{frq:xcommand_installieren})}
\label{sub:konzept_funktionsschicht_xcommand_installieren}
Gemäss der funktionalen Anforderung \reffrequirement{frq:xcommand_installieren} und dem Use Case \refusecase{uc:xcommand_installieren} gibt es zwei unterschiedliche Varianten, wie XCommands in der Erweiterung installiert werden können:
  	\begin{compactitem}
     \item Installation vom lokalen Filesystem
     \item Installation von einer Webseite
  	\end{compactitem}
Bevor ein XCommand installiert wird, überprüft die Erweiterung ob es sich um ein valides XCommand handelt. Verfügt ein XCommand über die optionale \verb|install()|"=Methode wird diese bei der Installation automatisch ausgeführt (\vgl{\autoref{tbl:struktur_xcommand_methoden}}).

\subsubsection{Installation vom lokalen Filesystem}
\label{subsubsec:konzept_funktionssicht_installation_vom_lokalen_filesystem}
Die Installation vom lokalen Filesystem erfolgt über den \acrshort{html}5 File \acrshort{api} Standard (\vgl{\cite[]{w3c2009storage}}). Dieser Standard erlaubt lokale Dateien mittels JavaScript zu öffnen und den Inhalt als ASCII-Text weiter zu verarbeiten.

\lstset{
   language=JavaScript,
   backgroundcolor=\color{lightgray},
   extendedchars=true,
   basicstyle=\footnotesize\ttfamily,
   showstringspaces=false,
   showspaces=false,
   numbers=left,
   numberstyle=\tiny,
   numbersep=9pt,
   tabsize=2,
   breaklines=true,
   showtabs=false,
   captionpos=t,
   columns=flexible,
   frame=single,
   breakautoindent=true,
}
\lstinputlisting[label=lst:fileApi,caption=Zugriff auf lokale Datei via File \acrshort{api}]{listings/file_api.js}

Der Code in \autoref{lst:fileApi} veranschaulicht exemplarisch wie einfach eine Datei vom lokalen Filesystem geöffnet und eingelesen werden kann. Nachdem eine Datei über ein \verb|<input type="file">| \acrshort{html}"=Element ausgewählt wurde, kann über das \verb|FileReader|"=Interface das \verb|File|"=Objekt des Input-Elements geöffnet und eingelesen werden. Das \verb|onload|"=Event des \verb|FileReader|"=Interfaces wird nach erfolgreichem Einlesen der Datei ausgelöst. Nach dem erfolgreichen Einlesen wird ein XCommand validiert und im \verb|localStorage| des Browser gespeichert.

\subsubsection{Installation von einer Webseite}
\label{subsubsec:konzept_funktionssicht_installation von einer Webseite}
Die Installation von einer Webseite erfolgt über ein Content Script. Das injizierte Script prüft ob die aktuelle Webseite XCommands anbietet. Eine Webseite die XCommands anbietet muss das XCommand mittels \verb|<link>|"=Tag im \acrshort{html}"=Dokument deklarieren:

\lstset{
   language=HTML,
   backgroundcolor=\color{lightgray},
   extendedchars=true,
   basicstyle=\footnotesize\ttfamily,
   showstringspaces=false,
   showspaces=false,
   numbers=left,
   numberstyle=\tiny,
   numbersep=9pt,
   tabsize=2,
   breaklines=true,
   showtabs=false,
   captionpos=t,
   columns=flexible,
   frame=single,
   breakautoindent=true,
}
\lstinputlisting[label=lst:linkTag,caption=\acrshort{html} Link-Tag zum identifizieren von XCommands]{listings/link_tag.html}

Der Code in \autoref{lst:linkTag} veranschaulicht welche Attribute das \verb|<link>|"=Tag benötigt, damit das Content Script ein XCommand auf einer Webseite identifiziert. Das \verb|rel|"=Attribut gibt als Beziehung den String ">xcommand"< an, somit weiss das Content Script, dass es sich beim angegebenen \verb|<link>|"=Tag um ein XCommand handeln muss. Das \verb|href|"=Attribut spezifiziert die URL zum verlinkten XCommand.

Implementiert eine Webseite das \acrshort{html}"=Konstrukt aus \autoref{lst:linkTag} erscheint eine Infobar mit einem Installations-Button am oberen Rand der Webseite und weisst den Besucher dieser Webseite darauf hin, dass diese Webseite ein XCommand enthält. Nachdem klicken des Installations-Button erscheint aus Sicherheitsgründen ein Bestätigungsdialog"=Fenster. Der Besucher kann in diesem Dialog"=Fenster den Source Code des XCommands begutachten und bestätigt anschliessend, dass das XCommand keinen korrupten JavaScript"=Code enthält, der seinem Browser oder Betriebssystem Schaden zuführen kann. Durch die Bestätigung wird das XCommand in der Erweiterung installiert.

\subsection[XCommand deinstallieren]{XCommand deinstallieren (\reffrequirement{frq:xcommand_deinstallieren})}
\label{sub:konzept_funktionsschicht_xcommand_deinstallieren}
Basierend auf der funktionalen Anforderung \reffrequirement{frq:xcommand_deinstallieren} können installierte XCommands in der Einstellungsseite der Erweiterung wieder entfernt werden.
Bei der Deinstallation wird die optionale \verb|deinstall()|"=Methode des XCommands ausgeführt. Über diese Methode können z.B. XCommand-spezifische Einstellungen, die während der Installation des XCommands im lokalen Speicher angelegt wurden, wieder entfernt werden.

\subsection[XCommand de- bzw. reaktivieren]{XCommand de- bzw. reaktivieren (\reffrequirement{frq:xcommand_deactivate})}
\label{sub:konzept_funktionsschicht_xcommand_deactivate}
Basierend auf der funktionalen Anforderung \reffrequirement{frq:xcommand_deactivate} können installierte XCommands temporär deaktiviert bzw. reaktiviert werden. Die De- bzw. Reaktivierung erfolgt über die Einstellungsseite der Erweiterung. Jedes installierte XCommand kann über eine Checkbox de- bzw. reaktiviert werden.

\subsection[XCommand updaten]{XCommand updaten (\reffrequirement{frq:xcommand_updaten})}
\label{sub:konzept_funktionsschicht_xcommand_update}
Gemäss der funktionalen Anforderung \reffrequirement{frq:xcommand_updaten} und dem Use Case \refusecase{uc:xcommand_updaten} muss die Erweiterung dass Updaten von XCommands unterstützen. Ein XCommand kann die optionale Eigenschaft \verb|update| enthalten (\vgl{\autoref{subsec:konzept_das_xcommand}}). Diese Eigenschaft muss eine gültige URL zu einer XCommand Update Manifest"=Datei haben. Beim XCommand Update Manifest handelt es sich um eine \acrshort{json}"=Datei mit der Struktur aus \autoref{lst:updateManifest}:

\lstset{
   language=JavaScript,
   backgroundcolor=\color{lightgray},
   extendedchars=true,
   basicstyle=\footnotesize\ttfamily,
   showstringspaces=false,
   showspaces=false,
   numbers=left,
   numberstyle=\tiny,
   numbersep=9pt,
   tabsize=2,
   breaklines=true,
   showtabs=false,
   captionpos=t,
   columns=flexible,
   frame=single,
   breakautoindent=true,
}
\lstinputlisting[label=lst:updateManifest,caption=XCommand Update Manifest]{listings/update.json}

Die XCommander Erweiterung überprüft bei der Initialisierung für jedes installierte XCommand mit der \verb|update|"=Eigenschaft, ob eine neue Version des XCommands vorhanden ist. 
Diese Überprüfung erfolgt über die Versionsnummer des XCommands. Sollte eine neue Version vorhanden sein, erscheint in der Einstellungsseite der Erweiterung unter dem betreffenden XCommand einen Update"=Link über den der Benutzer das Update installieren kann.

\subsection[XCommand ausführen]{XCommand ausführen (\reffrequirement{frq:xcommand_run})}
Gemäss der funktionalen Anforderung \reffrequirement{frq:xcommand_run} müssen XCommands in pseudo"=natürlicher Sprache ausgeführt werden können. Diese Funktionalität wird durch den \verb|XCommanderParser| konzipiert. Beim \gls{parser} handelt es sich um ein intelligenten \gls{parser} der auf semantischen Rollen basiert. Nachfolgend wird das Prinzip und das Konzept des \glspl{parser} detailliert erläutert.

\subsubsection{Grammatik der pseudo-natürlichen Sprache}
Mit Hilfe von semantischen Rollen lässt sich eine limitierte und stark vereinfachte Grammatik für eine pseudo-natürliche Sprache definieren. Das Konzept des \glspl{parser} für die XCommander Erweiterung basiert auf der deutschen Sprache und lässt sich grundsätzlich auch auf weiter germanische oder lateinische Sprachen adaptieren.

In Anlehnung an die Grammatik der deutschen Sprache unterstützt der \gls{parser} in einer reduzierten aber erweiterbaren Form Satz-Objekte als ">Präpositionalobjekte"< oder ">Direkte Objekte"<. Kommandos werden immer als Aufforderungssatz formuliert und interpretiert, daher steht das Verb immer an erster Stelle.
\newpage

Zusammenfassend muss jedes XCommand folgende Reglung beachten und in der Implementation berücksichtigen:
\begin{itemize}
  \item Der Name eines XCommands repräsentiert das Verb im Satz und steht immer an erster Stelle.
  \item Auf den Namen des XCommands können beliebige Argumente folgen. Jedes Argument entspricht einem Objekt im Satz und muss durch eine semantische Rolle und einen Noun Type beschrieben werden.
\end{itemize}

Im \autoref{cha:beispiel_role_nountype} wird das Konzept von semantischen Rollen und Noun Types anhand eines Beispiels genauer erläutert.

\subsubsection{Semantische Rollen}
Jede semantische Rolle definiert eine Liste von Präpositionen bzw. Konjunktionen, die einem Argument vorangestellt werden können und vom \gls{parser} erkannt werden. 

Die nachfolgende \autoref{tbl:semantische_rollen} beschreibt die Bedeutung einzelner semantischen Rollen.
\begin{longtable}{p{0.25\textwidth}p{0.60\textwidth}}
\caption{\gls{parser} - Semantische Rollen} \label{tbl:semantische_rollen}\\
   \hline
   \textbf{Rolle} & \textbf{Bedeutung}\\
   \hline\rowcolor[gray]{0.9}
   object & direktes Objekt im Satz \\
   source & Präpositionalobjekt, das eine örtliche Quelle oder einen Startpunkt beschreibt. \\\rowcolor[gray]{0.9}
   goal & Präpositionalobjekt, das ein örtliches Ziel oder Endpunkt beschreibt. \\
   time & Präpositionalobjekt, das ein Zeitpunkt beschreibt. \\\rowcolor[gray]{0.9}
   alias & Objekt das durch die Konjunktion ">als"< ein Referenz genauer beschreibt. \\
   \hline
\end{longtable}
Der \gls{parser} kann um beliebige semantische Rollen erweitert werden, um die Grammatik der pseudo-natürlichen Sprache zu verbessern.

\newpage
\subsubsection{Noun Types}
Der Noun Type spezifiziert die Art und das Format der Eingabe eines Arguments. Über den Noun Type lässt sich die Eingabe des Arguments validieren.

Die nachfolgende \autoref{tbl:noun_types} beschreibt die Bedeutung und das Eingabeformat einzelner Noun Types.
\begin{longtable}{p{0.25\textwidth}p{0.30\textwidth}p{0.30\textwidth}}
\caption{\gls{parser} - Noun Types} \label{tbl:noun_types}\\
   \hline
   \textbf{Noun Type} & \textbf{Bedeutung} & \textbf{Format}\\
   \hline\rowcolor[gray]{0.9}
   text & beliebiger Text & alphanumerisch \\
   date & Datum & dd.MM.yyyy\\\rowcolor[gray]{0.9}
   date\_time & Datum und Zeit & dd.MM.yyyy HH:mm \\
   time & Zeit & HH:mm\\
   \hline
\end{longtable}

Noun Types basieren auf regulären Ausdrücken. Die Liste der Noun Types kann um beliebige Noun Type erweitert werden. Neben den Noun Types aus \autoref{tbl:noun_types} werden auch einfache Listen (Arrays) als Noun Type akzeptiert.

\subsubsection{\gls{parser}}
Nach der Eingabe des XCommand Namens in der Kommandozeile wird mit jeder weiterer Eingabe in der Kommandozeile die \verb|parse()|"=Methode des \gls{parser} ausgeführt. 
Das Parsen erfolgt in zwei Schritten:
\begin{itemize}
  \item \textbf{\gls{tokenizer}:} Der Tokenizer generiert basierend auf der Grammatik (Semantische Rolle und Noun Type) für jedes Argument des XCommands ein Token. Jedes Token beschreibt das Argument des XCommands durch einen regulären Ausdruck. Die einzelnen Werte werden mit Hilfe der Gruppierungs-Funktion von regulären Ausdrücken extrahiert. 
  \item \textbf{\gls{syntaxanalyse}:} Mittels syntaktischer Analyse werden die vom Tokenizer extrahierten Tokens verarbeitet. Die Argumente werden anschliessend in strukturierter Form als Objekt gespeichert.
\end{itemize}

Nach jedem Parsing-Vorgang wird das strukturierte Objekt mit sämtlichen Argumenten der \verb|preview|-Methode des XCommands übergeben.